Strategies for Configuring Media Processing Functionality Using a Hierarchical Ordering of Control Parameters

ABSTRACT

Strategies for effectively discovering, selecting, configuring, and controlling components used in media processing applications are described. According to one exemplary implementation, the strategies described configure the components based on profile information, configuration information, and a hierarchical ordering of configuration parameters. The hierarchical ordering may combine different coding paradigms, where one or more high level nodes in the ordering may define configuration parameters which are common to multiple coding paradigms. In this ordering, selection of a configuration parameter may cascade down to affect lower-ranking dependent parameters in the hierarchical ordering. According to one advantage, the hierarchical ordering provides a more uniform, extensible, and problem-free approach to configuring components than unstructured approaches to configuration. Moreover, applications can utilize the hierarchical ordering at different levels of granularity.

REFERENCE TO COPENDING APPLICATIONS

This application is a continuation of co-pending U.S. application Ser.No. 11/172,251 entitled “Strategies for Configuring Media ProcessingFunctionality Using a Hierarchical Ordering of Control Parameters” filedon Jun. 30, 2005 which is a continuation-in-part of co-pending U.S.patent application Ser. No. 10/676,722 (the '722 Application), entitled“Systems and Methods for Interfacing Media Components,” filed on Sep.30, 2003, and naming Glenn F. Evans et al. as inventors. BothApplications are incorporated herein by reference in their entirety.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patentdisclosure, as it appears in the Patent and Trademark Office patentfiles or records, but otherwise reserves all copyright rightswhatsoever.

BACKGROUND

Media processing applications sometimes incorporate third partycomponents. For example, a principal application may perform ahigh-level media processing task (such as DVD authoring), and thehigh-level task may, in turn, rely on one or more third party componentsto perform basic operations encompassed by the task (such ascompressing, packetizing, multiplexing, and so on). An application mayadopt this implementation strategy for various reasons. For example, anapplication designer may wish to reduce the cost of the application byrelying on existing third-party components. Or an application designermay wish to rely on third party components (rather than building suchfunctionality into the application itself) for license-related reasons.

The task of selecting and configuring third party components may raise anumber of challenges. First, an application may have complexrequirements. The pool of available components may have equally complexcapabilities. It is a difficult task to match the requirements of anapplication with the capabilities of the components. Second, it is adifficult task to ensure that the selected third party components workwell together to achieve a desired end result. That is, one third partycomponent may have a set of features (and configuration states) whichconflict with the features (and configuration states) of one or moreother third party components. Such conflicts can produce a configurationhaving an inconsistent state, which may cause the combination ofcomponents to perform in a suboptimal manner. Or such conflict maycompletely disable the combination of components. Third, it is difficultto modify third party components to provide enhancements and extensionsto existing configurations, while still ensuring that these componentsconsistently work with applications which may be unaware of suchextensions.

The above challenges can be addressed in an ad hoc manner by a designinga custom configuration solution for each application. But this approachis problematic. For instance, to avoid configuration problems, thisapproach may require the application designer to have intimatefamiliarity with the media processing requirements, of the application,the capabilities of different components, and the manner in whichdifferent components interact. This approach may also require thedesigner to have expert knowledge of complex algorithms used bydifferent multimedia compression storage formats. Further, this approachmay also require the end-user to have advanced knowledge of mediaprocessing options in order to properly interact with the application,that is, by inputting configuration parameters into the user interfacepresentations provided by the application. Any misstep by theapplication designer or the end-user may produce an inconsistent statein the selected combination of components, possibly rendering theapplication non-functional. For example, as appreciated by the presentinventors, the order in which configuration parameters are set isimportant; if the parameters are not set in an appropriate order, thenthe combination of components may be placed in an inconsistent state.

Moreover, the ad hoc approach is generally not extensible, meaning thatit cannot be easily modified to suit variations in the applicationenvironment or the pool of available components. For instance, anymodification to the configuration settings may require difficultanalysis and significant design modification to ensure that the changesdo not produce an inconsistent state. Again, this task may requireexpert knowledge in media processing arts.

According to another challenge, the application designer may attempt todesign media processing functionality that supports a wide variety ofmedia storage formats. An application designer may address thisobjective by creating a complex abstraction software layer that makesdifferent formats appear “similar” for user interface and configurationpurposes. But this is a difficult task that adds complexity and cost tothe media processing functionality. Such a cumbersome abstraction layermay also provide poor extensibility with respect to future modificationsmade to the application, components, media formats, and so forth.

There is therefore an exemplary need for more satisfactory solutions fordiscovering, selecting, configuring, and controlling components used inmedia processing applications.

SUMMARY

This description sets forth strategies for more effectively discovering,selecting, configuring, and controlling components used in mediaprocessing applications. According to one exemplary implementation, thestrategies configure the components based on profile information,configuration information, and a hierarchical ordering of configurationparameters. The hierarchical ordering may combine different codingparadigms. For example, in one exemplary hierarchical ordering, atop-most node defines configuration parameters that apply to anycomponent used in a combination of components (such as any videoencoder, audio encoder, multiplexer, etc.), regardless of codingparadigm. A second level of the ordering may contain a node that definesconfiguration parameters that apply to any video encoder (regardless ofcoding paradigm), another node that defines configuration parametersthat apply to any audio encoder (regardless of coding paradigm), anothernode that defines configuration parameters that apply to anypacketizer/multiplexer (regardless of coding paradigm), and so forth.Still other subordinate layers in the hierarchical ordering may containnodes associated with specific video encoder coding paradigms, audioencoders coding paradigms, and multiplexer coding paradigms, and soforth. In this ordering, the selection of a configuration parameter maycascade down to affect lower-ranking dependent parameters in thehierarchical ordering.

According to another feature, the components can be combined in adefined order, wherein at least one downstream component is establishedprior to at least one upstream component.

The above approach has several benefits. According to one exemplarybenefit, the hierarchical ordering, in conjunction with the use ofprofile information and configuration information, provides a uniformapproach to discovering, selecting, configuring, and controlling mediacomponents. This approach eases the analysis burden in configuringcomponents because it provides a well-defined and consistent approach toselecting and configuring components. The approach also reduces thepotential that a user (or an automated mechanism) will select andconfigure a combination of components that will produce an inconsistentstate.

Further, the approach offers improved versatility and extensibility overad hoc approaches. As to versatility, different applications can utilizethe hierarchical ordering at different levels of granularity andconfiguration complexity and generality. For instance, a firstapplication may rely on the hierarchical ordering to configure acollection of components at a relatively low level of granularity,setting only very general-level configuration parameters. In this firstapplication, a variety of different coding paradigms can be applied tosatisfy the application's requirements. On the other hand, a secondapplication may rely on the hierarchical ordering to configure acollection of components at a relatively high level of granularity, thatis, by setting relatively detailed configuration parameters (such asparameters that pertain to a specific coding paradigm). In this secondapplication, the parameters may specifically target one or more codingparadigms. In either case, the applications can be configured to supplyuser interface presentations to the users which solicit only thosefields of information that are relevant to configuring, and controllingthe applications. This feature helps reduce the complexity of the userinterface presentations and improves the experience of the users wheninteracting with the applications.

As to extensibility, the approach accommodates the introduction of newparameters. That is, the approach allows new parameters to be integratedinto the hierarchical ordering without requiring modification of thebasic organization of the ordering itself.

Additional exemplary implementations and associated benefits aredescribed in the following. It should be noted that the featuresdescribed in this Summary section are intended to convey exemplaryaspects of the subject matter described herein, and are not intended tolimit the scope of the subject matter described in the Claim section.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an overview of a system for discovering, selecting,configuring, and controlling a collection of components for use in amedia processing application.

FIG. 2 shows a procedure which explains an exemplary manner of operationof the system of FIG. 1.

FIG. 3 shows an exemplary combination of components (a “componentmodule”) that can be created using the system of FIG. 1.

FIG. 4 shows an exemplary hierarchical ordering of configurationparameters that can be used in the system of FIG. 1.

FIG. 5 shows a more detailed version of the hierarchical ordering shownin FIG. 4.

FIG. 6 shows a procedure which explains an exemplary manner in which onelayer in the hierarchical ordering (of FIGS. 4 and 5) can potentiallyaffect subordinate layers in the hierarchical ordering.

FIG. 7 shows an exemplary procedure for establishing components in adefined exemplary order.

FIG. 8 shows an exemplary computer environment for implementing thesystem of FIG. 1.

The same numbers are used throughout the disclosure and figures toreference like components and features. Series 100 numbers refer tofeatures originally found in FIG. 1, series 200 numbers refer tofeatures originally found in FIG. 2, series 300 numbers refer tofeatures originally found in FIG. 3, and so on.

DETAILED DESCRIPTION

This description sets forth exemplary strategies for discovering,selecting, configuring, and controlling components for use in a mediaprocessing application.

As to terminology, the term “component” refers to any unit designed toprocess information. A component can be implemented as a hardware unit,software unit, or a unit that comprises a combination of hardware andsoftware. A component may comprise a single “part,” such as a singlepiece of hardware and/or software that is purchasable as a unit, or itcan comprise a combination of multiple such parts. In one case, acomponent can be provided by a third party provider (meaning that theentity which supplies the main media processing application is differentthan the entity which provides the component). In another case, thecomponent can be supplied by the same entity that provides the mainmedia processing application.

The term “media information” refers to any data represented inelectronic form that can be consumed by a user. The media informationcan include any information that conveys audio and/or video information,such as audio resources (e.g., music, spoken word subject matter, etc.),still picture resources (e.g., digital photographs, etc.), movingpicture resources (e.g., audio-visual television media programs, movies,etc.), and so on.

The term “media processing application” refers to an application forprocessing media information to achieve any end result. One example of amedia processing application is a DVD authoring application.

The term “component module” refers to a group of one or more componentsthat are used in a media processing application. For example, a codecgrouping which combines encoders, packetizers and a multiplexer is oneexample of a component module.

The term “coding paradigm” refers very broadly to a set of rules thatapply to the interpretation, creation and control of data. For aparticular paradigm, the rules may be promulgated by a standardsorganization, by a commercial entity, or some other source. For example,MPEG (Moving Picture Experts Group) (e.g., MPEG2 or ISO/IEC 13818)defines one coding paradigm. SMPTE VC1 (Society of Motion PictureTelevision Engineers, standard VC1) (also referred to as WMV or WindowsMedia Video) defines another coding paradigm, and so forth.

Generally, any of the functions described with reference to the figurescan be implemented using software, firmware (e.g., fixed logiccircuitry), manual processing, or a combination of theseimplementations. The term “logic, “module” or “functionality” as usedherein generally represents software, firmware, or a combination ofsoftware and firmware. For instance, in the case of a softwareimplementation, the term “logic,” “module,” or “functionality”represents program code (or declarative content) that performs specifiedtasks when executed on a processing device or devices (e.g., CPU orCPUs). The program code can be stored in one or more computer readablememory devices. More generally, the illustrated separation of logic,modules and functionality into distinct units may reflect an actualphysical grouping and allocation of such software and/or hardware, orcan correspond to a conceptual allocation of different tasks performedby a single software program and/or hardware unit. The illustratedlogic, modules and functionality can be located at a single site (e.g.,as implemented by a processing device), or can be distributed overplural locations.

This disclosure includes the following sections.

Section A presents an overview of an exemplary system for creating acombination of components (a “configuration module”) for use in a mediaprocessing application. Section A also sets forth an exemplary manner ofoperation of the system.

Section B describes one exemplary component module that can be createdusing the system of Section A.

Section C describes an exemplary hierarchical organization ofconfiguration parameters that can be used to create the component moduleof section B.

Section D describes an exemplary computer environment for implementingaspects of the system of Section A.

Section E constitutes a first appendix (which forms an integral part ofthis disclosure), setting forth an exemplary collection of configurationparameters that can be used to populate the hierarchical ordering ofcontrol parameters described in Section C.

Section F constitutes a second appendix (which forms an integral part ofthis disclosure), setting forth an exemplary program listing of acodecapi.h module that can be used to implement aspects of theconfiguration strategies.

A. Overview of Exemplary System and its Manner of Operation

FIG. 1 shows an overview of a system 100 for discovering, selecting,configuring, and controlling a collection of components for use in amedia processing application. Certain features of this system 100 wereset forth in the above-identified co-pending patent application Ser. No.10/676,722 (the '722 Application). It should be noted that, although thestrategies described herein for configuring components (which rely on ahierarchical ordering of parameters) can be implemented using theframework set forth in the '722 Application, these strategies are notlimited to that framework.

The system 100 includes a media processing application 102 (or just“application” for brevity) for performing a media processing operation(such as DVD authoring, etc.). To perform its function, the application102 may rely on a collection of components drawn from a pool ofavailable components 104. As previously described, the components 104can represent hardware units, software units, hybrid units implementedin both hardware and software, and so forth. The components 104 can beprovided by the same entity which provides the application 102, or by adifferent (“third party”) entity.

Broadly stated, the components receive input media information (videoand/or audio information), provide some kind of transformation of theinput information to provide transformed information, and then outputthe transformed information. Exemplary kinds of components includevarious types of video encoders, various types of audio encoders,various types of packetizers and multiplexers, and so forth. A videoencoder refers to any kind of unit which transforms video informationfrom one form to another. The video encoder may, for instance, compressthe video information, scale the video information, change its colorspace, and so forth. Similarly, an audio encoder refers to any kind ofunit which transforms audio information from one form to another. Apacketizer refers to a unit which breaks video or audio information intopackets having a defined size. Typically, packets include headers andpayloads; the headers contain metadata which describes features of theinformation stored in the payloads, such as timing-related informationassociated with the information stored in the payloads. A multiplexer isa device which combines two or more signals into a composite signal. Forexample, a multiplexer can receive a stream of video information and astream of audio information and produce an output that comprisesinterleaved packets of video and audio information. The components 104can include yet other kinds of units not mentioned above.

Interface functionality 106 allows the application 102 to interact withthe components 104. One function that the interface functionality 106can perform is to handle the registry of components 104. In performingthis function, the interface functionality 106 records salientinformation (e.g., metadata) regarding new components added to the poolof available components 104. Another function that the interfacefunctionality 106 performs is to discover the available components 104,and, in particular, to determine the components which are available thatcan perform one or more tasks required by the application 102. Inperforming this function, the interface functionality 106 can comparethe requirements of the application with the capabilities of thecomponents 104 and select a group of components which satisfy therequirements. Another function that the interface functionality 106performs is to configure the selected components. In performing thisfunction, the interface functionality 106 can set various parametersthat govern the manner in which the selected components operate.According to another function, the interface functionality 106 cancontrol the operation of the selected group of components (collectivelyforming a “component module”), and can monitor its operation. Inperforming this function, the interface functionality 106 can collectstatistical information regarding the operation of the component module.The interface functionality 106 can use this statistical information toimprove the performance of the application 102. The following discussionprovides more details regarding the above-identified functions and otheraspects of the interface functionality 106.

In terms of physical implementation, the application 102 and interfacefunctionality 106 can be implemented as two respective logic modules(implemented in hardware and/or software) provided by a computingdevice. For example, the application 102 can be implemented as anapplication program, and the interface functionality 106 can beimplemented as an application programming interface (API). FIG. 7provides one illustrative example of a computing environment that can beused to implement the application 102 and the interface functionality106. In another exemplary implementation, the application 102 and theinterface functionality 106 can be implemented using two separate units.For example, one or more features of the interface functionality 106 canbe implemented as a detachable card which is communicatively coupled toa computer device which implements the application 102. Still furtherimplementation permutations are possible.

The components 104 can likewise represent hardware and/or software unitswhich are physically implemented by the same mechanism which implementsthe application 102 and/or interface functionality 106. For example, thecomponents 104 may represent software units which are executed by thesame computer device which implements the application 102 and/or theinterface functionality 106. Alternatively, one or more of thecomponents 104 can be implemented by a unit (such as a detachable card)which is separate from (but communicatively coupled to) the device whichimplements the application 102 and/or interface functionality 104. Stillfurther implementation permutations are possible.

In any event, the interface functionality 106 can include managementlogic 108 for performing all the prescribed tasks assigned to theinterface functionality 106. These tasks include at least theabove-identified operations, such as registering components, discoveringcomponents, selecting components which match the requirements of theapplication 102, configuring the components, monitoring the operation ofthe components, and so forth.

The interface functionality 106 also includes a profile store 110. Theprofile store 110 stores profiles. A profile specifies configurationinformation that can be used to select and configure a group ofcomponents 104 to perform a prescribed task. For example, a DVD profilecan contain parameters used to configure a pipeline to produce a DVDcompliant output stream. The profile can contain: name information whichidentifies the profile; encoder/mux/packetizer parameters and media typedescriptions; valid ranges associated with the operation of thecomponent module to be built; a list of capabilities to filter candidatecomponents by; a list of critical configuration parameters, and soforth. The application 102 can use a profile stored in the profile store110 to provide “pre-canned” instructions to create a desired componentmodule. For instance, supposing that the application needs to performfunction X, it can identify, in the profile store 110, a profile P_(x)which specifies how to create and configure a component module toperform function X. Actual creation of the component module comprisescarrying out the instructions in the profile.

The interface functionality 106 also includes a component capabilitystore 112. The capability store 112 stores capability lists. Eachcapability list describes the capabilities of a component, such as thecharacteristics of the components, its operating limitations, and soforth. The application 102 finds satisfactory components by comparingthe requirements specified in a selected profile with the componentcapabilities advertised in the component capability store 112.

In one exemplary implementation, different elements of the profiles,capability lists, and configuration parameters can be identified usingappropriate identifiers, such as GUIDs. For example, each distinctcapability of a component can be identified with a different GUID. TheseGUID identifiers help manage and locate desired components. For example,a profile may specify one or more GUIDS, enabling the management logic108 to determine whether there are any components which satisfy thefeatures associated with the GUIDs by determining if there are matchingGUIDs in the component capability store 112.

Although not shown in FIG. 1, the interface functionality 106 can alsoinclude a store for storing a hierarchical listing of configurationparameters used to configure a component module (in the manner to bedescribed below).

FIG. 2 shows a procedure 200 which explains an exemplary manner ofoperation of the system 100 shown in FIG. 1. To facilitate discussion,certain operations are described as constituting distinct stepsperformed in a certain order. Such implementations are exemplary andnon-limiting. Certain steps described herein can be grouped together andperformed in a single operation, and certain steps can be performed inan order that differs from the order employed in the examples set forthin this disclosure.

In step 202 of the procedure 200, the management logic 108 receives arequest to perform a task which will require the use of a componentmodule.

In step 204, the management logic 108 locates a profile in the profilestore 110 associated with the desired task. As mentioned above, thelocated profile describes how to create and configure a component modulethat will perform the desired task.

In step 206, the management logic 108 can find the component (orcomponents) in the pool of available components 104 which can performthe selected profile. As mentioned above, this can be performed bymatching the requirements of the profile with the attributes specifiedin the component capability store 112. In one case, this matchingprocedure can have at least two phases. In a first phase, the managementlogic 108 can identify components for which there is an expressone-to-one match between specified application requirements andcomponent capabilities. If all the requirements are not met in the firstphase, in a second phase, the management logic 108 can re-examine anycomponent for which there is no express match, but which mightnevertheless possess the features necessary to satisfy the applicationrequirements. For example, an application requirement might state, “finda component that has property Y.” The first pass examines the componentcapability store 112 to determine whether there are any components whichexpressly state that they have the desired property. Some components mayexpressly state that they do not have this feature. These components areexcluded from the search. But other components might not advertise thatthey have the desired feature, but may nonetheless still possess thisfeature. In the second phase, the management logic 108 will attempt tosatisfy unmet requirements by re-examining any component which does notexpressly conflict the application's requirements.

In step 208, the management logic 108 constructs the component modulewhich will perform the desired task using the components selected instep 206. The component module is created in a specific manner, e.g., byadding components in a specified order, and setting configurationparameters in a specified order. This restraint helps reduce thepossibility that the component module will be placed in an inconsistentstate. As previously described, an inconsistent state is a state inwhich one component includes settings or requirements which conflictwith the settings or requirements of another component (or components).An inconsistent state may impair the performance of the application 102,or completely disable the application 102.

Although not shown in FIG. 2, after the component module is created, theprocedure 200 can monitor the performance of the component module. Thisis useful in order to collect statistical information regarding theoperation of the component module, so as to improve the performance ofthe component module, and so forth. The interface functionality 106 cancollect performance data by registering one or more events; upon theoccurrence a registered event during the operation of the componentmodule, the interface functionality 106 can log the event for use informing statistics.

In one exemplary implementation, in performing the above operations, thepotential candidate components can be enumerated and pre-filteredwithout actually creating an instance of each component. This featuremakes the processing described above more efficient.

B. Exemplary Component Module

FIG. 3 shows an exemplary component module 300. The component module 300includes a collection of components selected from the pool of availablecomponents 104. The purpose of any component module is to receiveinformation from an origin 302, perform some processing operation on theinformation to provide transformed information, and to supply to thetransformed information to a destination (sink) 304.

The origin 302 may represent an original capture device which firstproduces the information. For example, the origin 302 may represent avideo camera which captures audio-visual information. Alternatively, theorigin 302 may represent any kind of source of pre-recorded information,such as audio-visual information retrieved from a file, a disk, a tape,a digital network, and so forth. The destination 304 may likewise havedifferent connotations depending on different implementations. In onecase, the destination 302 may represent a storage that is used toreceive the transformed information produced by the component module300. In another case, the destination may represent an output device(such as any kind of audio-visual output device) for presenting thetransformed information. A television is one such output device. Inanother case, the destination may represent some target site coupled toa digital network. These are merely representative examples of possibleorigins 302 and destinations 304.

The specific combination of components shown in FIG. 3 performs anoperation in which video information and audio information are encoded,and then this encoded information is broken up into packets which areinterleaved together to form a final output result. More specifically,the source information received form the origin 302 may include twocomponents: video information 306 and audio information 308. A videoencoder 310 encodes the video information 306, while an audio encoder312 encodes the audio information 308. Encoding can comprisetransforming the information in any way, such as by compressing theinformation, changing the color space of the information, and so forth.

A video packetizer 314 receives the output of the video encoder 310 andbreaks this output up into a series of video packets. An audiopacketizer 316 receives the output of the audio encoder 312 and breaksthis output up into a series of audio packets. As described above, eachpacket can include header information and payload information. Theheader information contains metadata which describes the payloadinformation. For example, the header information may include timestampinformation which describes the timing at which the informationcontained in the payload was captured, received, or otherwise subjectedto some identified processing. FIG. 3 shows the packetizers (314, 316)as forming discrete units which are coupled to the output of theencoders (310, 312). This is one possibility. In another case, however,the packetizers (314, 316) can be integrated into the respectiveencoders (310, 312). In another case, the packetizers (314, 316) can beintegrated in the multiplexer 318.

The multiplexer 318 itself receives the output of the packetizers andcombines the packetized video information with the packetized audioinformation into a single stream of information. The multiplexer 318 canperform this combination by interleaving the video information with theaudio information according to a defined format. The component module300 then forwards the interleaved stream to the destination 304.

To repeat, the composition of the component module 300 shown in FIG. 3is merely exemplary. Other arrangements are possible.

According to one exemplary implementation, the interface functionality106 creates the component module 300 in a predefined order so as toreduce the possibility of producing an inconsistent state. Generally,the build process proceeds by constructing the pipeline topology fromthe multiplexer to the encoders. The following presents an overview ofan exemplary build order:

1) Define/create the origin 302 and destination 304.

2) Create and configure the multiplexer 318.

3) Connect the output of the multiplexer 318 to the destination 304.

4) Create and configure the encoders (310, 312).

5) Connects the output of the encoders (310, 312) to the multiplexer 318(via the packetizers, if these are present as separate units).

6) Finish configuring the component module.

In one case, the pipeline is constructed using a profile. The followingexemplary list of operations describes one way of creating the componentmodule using the profile:

1) Define/create the destination 304.

2) Build an encoding and multiplexing topology.

-   -   a) Select the multiplexer 318.    -   b) Configure the multiplexer 318 based on an applicable profile,        including a number of input streams.    -   c) Connect the multiplexer 318 to the destination 304.    -   d) For each multiplexer input:        -   i. Select an encoder (310, 312).        -   ii. Configure the encoder (310, 312) based on the profile.        -   iii. Connect the encoder (310, 312) to the multiplexer's            input.

3) Create the media's video and audio sources (origin 302).

4) Join the source (origin 302) to the partially built encodingtopology.

This order of operations described above is representative; otherorderings are possible.

One general feature of the exemplary approach described above is that acomponent can be configured and then logically connected to a downstreamcomponent. By virtue of this feature, it is possible to effectivelyaddress, in a structured manner, many conflicts and ambiguities that mayoccur in the course of component configuration. For example, a typicalproblem occurs when the source image size does not match the image sizespecified for a particular encoding task. For instance, DVD movies aretypically compressed at a resolution of 720×480 pixels. If the sourcecontent is at 1920×1080 pixels, then it may be unclear which componentin a combination of components should scale (e.g., “shrink”) the imageto the appropriate size. By configuring the output resolution setting onthe encoder, the encoder can choose to scale down the input content ifpossible. If the encoder is unable to scale down the image resolution,then this component can indicate (e.g., by connection failure) to theentity building the topology that the image source needs to scale downthe size of the image. If that option fails, then the entity can createa generic image processing object to reduce the size of the image.

C. Exemplary Ordering of Configuration Parameters

FIG. 4 shows an exemplary ordering 400 of configuration parameters. Theconfiguration parameters are used to define the configuration of thedifferent components shown in FIG. 3 (or the configuration of some otherkind of component module not shown). The parameters can be set byassociated functionality (e.g., API functionality) provided by theinterface functionality 106. Thus, the ordering 400 shown in FIG. 4 isalso representative of the organization of API functionality used to setthe indicated parameters. This section provides an overview of theordering 400 shown in FIG. 4, while Section E describes, in greaterdetail, exemplary parameters that can populate the ordering 400.

In general, the parameters shown in FIG. 4 define a collection of nodes.The nodes form a tree of parameters, where each node may have one ormore child nodes, and each child node may have, in turn, one or more ofits own child nodes, and so forth. The parameters become increasinglymore detailed as the tree is traversed from “top” to “bottom.” Forexample, one or more top-level nodes define a collection of parameterswhich may apply to a wide variety of components and coding paradigms. Inthis sense, these parameters define component-agnostic and codingparadigm-agnostic settings. On the other hand, lower level parametersmay more narrowly pertain to specific components and/or codingparadigms.

One general characteristic of the ordering 400 is top-downconfiguration-dependence. According to this characteristic, a change ina top-level parameter in the ordering 400 may affect lower-rankingdependent parameters (if they exist). In another words, if a change ismade to a parent parameter, then the interface functionality 106 maypropagate this change down the ordering 400 to make complementarychanges to child parameters, grandchild parameters, and so forth. Forexample, a user may select a parameter associated with a relativelyhigh-level node. This parameter may create a conflict with pre-existingchild node parameters, requiring a change to be made to the child nodeparameters to rectify this conflict. In some cases, rectifying aconflict may require disabling one or more components (or features ofcomponents) that serve no useful function after a change has been madeto a top-level parameter.

The use of the hierarchical ordering 400 shown in FIG. 4 has numerousbenefits. According to one benefit, the application 302 can configurethe component module 300 at various levels of granularity depending onthe demands of the application. For example, one application can allow auser to configure the component module 300 (or can automaticallyconfigure the component module 300) at a relatively high-level, settingonly general parameters relevant to certain broad aspects of theoperation of the component module 300. On the other hand, anotherapplication can allow a user to configure the component module 300 (orcan automatically configure the component module 300) at a relativelydetailed level, setting a number of format-specific parameters thatserve to fine-tune the operation of the component module 300. Thisvariable-grained approach is advantageous because it does not burden theuser by requiring the user to specify a host of parameters which have nobearing on performance features that the user considers important. Torepeat, regardless of the level of detail in which an applicationconfigures a component module, it draws from the same stock ordering400, essentially exposing different depths of the ordering 400 inconfiguring the component module.

According to another general benefit, the strong ordering 400 shown inFIG. 4 helps reduce the potential that the component module 300 will beconfigured in a manner that will produce an inconsistent state. In oneexemplary implementation, parameters should be generally defined in atop-down manner, in which the user makes top-level parameter selectionsprior to lower-level parameter selections. In those cases where the useris permitted to make configuration choices, the application 102 cantailor the user interface presentations as selection progresses, thatis, by removing selection options that no longer pertain to a prevailingstate of a configuration operation.

According to another benefit, the ordering 400 shown in FIG. 4represents a standardized approach to configuring component modules.Such standardization produces a highly extensible design approach.Namely, the ordering 400 permits new configuration parameters to beorderly added to the tree, and out-of-date configuration parameters tobe removed from the tree without requiring detailed re-engineering ofthe configuration strategy as a whole. New configuration parameters areadded to the existing order 400 at an appropriate location in the tree,based on the classification of the new parameters.

With the above introduction, further details will be provided belowregarding exemplary nodes within the ordering 400. Section E (below)provides yet more detailed information regarding the parameters shown inFIG. 4.

To begin with, a top-level node 402 represents parameters that apply toany component within the component module 300 (including encoders,packetizers, multiplexers, and so forth). This node 402 also representsparameters that can apply to any coding paradigm used by the components.The parameters associated with this node 402 are therefore relativelybasic and general-purpose in nature.

At the next level, node 404 represents parameters that apply to any kindof video encoder, regardless of the coding paradigm used by the videoencoder. Node 406 represents parameters that apply to any kind of audioencoder, regardless of the coding paradigm used by the audio encoder.Node 408 represents parameters that can apply to any packetizer and/ormultiplexer, regardless of coding paradigm. (Note that the packetizersand multiplexer may represent distinct components in the componentmodule 300, or the packetizers may be combined with the encoders or themultiplexer; at this level of explanation, however, the packetizers andmultiplexers are lumped together as a single topic of explication.)

At the next level in the hierarchical ordering 400, nodes 410 and 412represent parameters that pertain to broad classes of defined videocoding paradigms. Nodes 414 and 416 represent parameters that pertain tobroad classes of audio coding paradigms. Although only two video codingparadigms (410, 412) and two audio coding paradigms (414, 416) are shownin FIG. 4, the reader will appreciate that the ordering 400 can includeadditional coding paradigms.

At the next level, nodes 418 and 420 represent parameters that pertainto two particular species of the general video coding paradigmassociated with node 410. Nodes 422 and 424 represent parameters thatpertain to two particular species of the general audio coding paradigmassociated with node 414. Although only two video coding paradigmspecies (418, 420) and two audio coding paradigm species (422, 424) areshown in FIG. 4, the reader will appreciate that the ordering 400 caninclude additional coding paradigm species. Moreover, there can be yetfurther levels in the ordering 400 (not shown in FIG. 4).

FIG. 5 provides one specific implementation of the ordering 400 shown inFIG. 4. The top-level nodes in the order 500 shown in FIG. 5 correspondto the top-level nodes shown in FIG. 4. Namely, root node 502 representsparameters that apply to any component in the component module 300, andencompass any coding paradigm. Node 504 represents parameters that applyto any video encoder regardless of coding paradigm. Node 506 representsparameters that apply to any audio encoder regardless of codingparadigm. Node 508 represents parameters that apply to any multiplexer,regardless of coding paradigm.

In the next level, node 510 represents MPEG (Moving Picture ExpertsGroup) parameters that are specifically associated with the MPEG codingparadigm. Node 512 represents SMPTE VC1 (Society of Motion PictureTelevision Engineers, standard VC1) (also referred to as WMV or WindowsMedia Video) parameters that are specifically associated with the WMVcoding paradigm. Node 514 represents AC3 (Audio Coding Revision 3)parameters that are specifically associated with the AC3 codingparadigm. Node 516 represents WMA (Windows Media Audio) parameters thatare associated with the WMA coding paradigm.

In the next level, nodes 512 and 520 represent two specific MPEG codingparadigms for processing video information, namely the MPEG1 standard(ISO/IEC 11172) and the MPEG2 standard (ISO/IEC 13818). Although notshown, the hierarchical ordering can also incorporate a nodecorresponding to the H.264 standard (MPEG-4 Part 10, ISO/IEC 14496-10,Advanced Video Coding (AVC)), as well as other formats.

Once again, the nodes shown in FIG. 5 may represent a sampling of a moreencompassing tree of configuration nodes (not shown). In other words,the ordering 500 can encompass more nodes (not shown) associated withadditional kinds of components, coding paradigms, and so forth.

FIG. 6 represents one of the above-identified characteristics of theordering (400, 500) in flowchart form. Namely, the procedure 600 shownin FIG. 6 conveys the fact that a selection of a high-level parametermay affect dependent lower-level parameters.

In step 602, the interface logic 106 receives the user's selection of aparameter that has at least one child parameter dependent thereon. Orstep 602 may indicate the receipt of an automatic selection of aparameter.

In step 604, the interface logic 106 determines whether the high-levelchange requires any complementary changes to made in dependentlower-level parameters, and, if so, makes those changes. If appropriate,step 604 can involve notifying the user of the need to make certainselections, and receiving input from the user to reflect the user'schoices.

FIG. 7 describes an exemplary procedure 700 for establishing componentsin a defined order (as explained in greater detail in the previoussection).

In step 702, at least one multiplexing component is established.

In step 704, at least one packet-forming component per multiplexer inputstream is established.

In step 706, at least one media encoder is established.

D. Exemplary Computer Environment

As described above, certain aspects of the system 100 shown in FIG. 1can be implemented using a computer device. For example, certain aspectsof the application 102, interface functionality 106 and components 104can be implemented by a computing device. In another implementation, oneor more aspects of the system 100 can be implemented by a separatedevice (such as a processing card) which interacts with the computerdevice. In any event, FIG. 8 shows an exemplary computer environment 800which can implement aspects of the system 100 shown in FIG. 1.

The computing environment 800 includes a general purpose or sever typecomputer 802 and a display device 804. However, the computingenvironment 800 can include other kinds of computing equipment. Forexample, although not shown, the computer environment 800 can includehand-held or laptop devices, set top boxes, game consoles, etc. Further,FIG. 8 shows elements of the computer environment 800 grouped togetherto facilitate discussion. However, the computing environment 800 canemploy a distributed processing configuration. In a distributedcomputing environment, computing resources can be physically dispersedthroughout the environment.

Exemplary computer 802 includes one or more processors or processingunits 806, a system memory 808, and a bus 810. The bus 810 connectsvarious system components together. For instance, the bus 810 connectsthe processor 806 to the system memory 808. The bus 810 can beimplemented using any kind of bus structure or combination of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures.

Computer 802 can also include a variety of computer readable media,including a variety of types of volatile and non-volatile media, each ofwhich can be removable or non-removable. For example, system memory 808includes computer readable media in the form of volatile memory, such asrandom access memory (RAM) 812, and non-volatile memory, such as readonly memory (ROM) 814. ROM 814 includes an input/output system (BIOS)816 that contains the basic routines that help to transfer informationbetween elements within computer 802, such as during start-up. RAM 812typically contains data and/or program modules in a form that can bequickly accessed by processing unit 806.

Other kinds of computer storage media include a hard disk drive 818 forreading from and writing to a non-removable, non-volatile magneticmedia, a magnetic disk drive 820 for reading from and writing to aremovable, non-volatile magnetic disk 822 (e.g., a “floppy disk”), andan optical disk drive 824 for reading from and/or writing to aremovable, non-volatile optical disk 826 such as a CD-ROM, DVD-ROM, orother optical media. The hard disk drive 818, magnetic disk drive 820,and optical disk drive 824 are each connected to the system bus 810 byone or more data media interfaces 828. Alternatively, the hard diskdrive 818, magnetic disk drive 820, and optical disk drive 824 can beconnected to the system bus 810 by a SCSI interface (not shown), orother coupling mechanism. Although not shown, the computer 802 caninclude other types of computer readable media, such as magneticcassettes or other magnetic storage devices, flash memory cards, CD-ROM,digital versatile disks (DVD) or other optical storage, electricallyerasable programmable read-only memory (EEPROM), etc.

Generally, the above-identified computer readable media providenon-volatile storage of computer readable instructions, data structures,program modules, and other data for use by computer 802. For instance,the readable media can store the operating system 830,application-specific functionality 832 (including functionality forimplementing aspects of the application 102), other program modules 834,and program data 836. One or more of the above-identified computerreadable media can also implement aspects of the interface functionality106 and the components 104. In cases were one or more of the componentsrepresent hardware units (not shown in FIG. 8), these units can interactwith the components shown in FIG. 8 through appropriate couplinginterfaces (such as coupling mechanisms associated with processingcards).

The computer environment 800 can include a variety of input devices. Forinstance, the computer environment 800 includes the keyboard 838 and apointing device 840 (e.g., a “mouse”) for entering commands andinformation into computer 802. The computer environment 800 can includeother input devices (not illustrated), such as a microphone, joystick,game pad, satellite dish, serial port, scanner, card reading devices,digital or video camera, etc. Input/output interfaces 842 couple theinput devices to the processing unit 806. More generally, input devicescan be coupled to the computer 802 through any kind of interface and busstructures, such as a parallel port, serial port, game port, universalserial bus (USB) port, etc.

The computer environment 800 also includes the display device 804. Avideo adapter 844 couples the display device 804 to the bus 810. Inaddition to the display device 804, the computer environment 800 caninclude other output peripheral devices, such as speakers (not shown), aprinter (not shown), etc.

Computer 802 operates in a networked environment using logicalconnections to one or more remote computers, such as a remote computingdevice 846. The remote computing device 846 can comprise any kind ofcomputer equipment, including a general purpose personal computer,portable computer, a server, etc. Remote computing device 846 caninclude all of the features discussed above with respect to computer802, or some subset thereof.

Any type of network 848 can be used to couple the computer 802 withremote computing device 846, such as the WAN 402 of FIG. 4, a LAN, etc.The computer 802 couples to the network 848 via network interface 850(e.g., the interface 416 shown in FIG. 4), which can utilize broadbandconnectivity, modem connectivity, DSL connectivity, or other connectionstrategy. Although not illustrated, the computing environment 800 canprovide wireless communication functionality for connecting computer 802with remote computing device 846 (e.g., via modulated radio signals,modulated infrared signals, etc.).

E. Appendix 1: Exemplary Parameters

This section provides additional information regarding one exemplaryimplementation of the ordering 400 of parameters introduced in thecontext of FIG. 4, and associated topics.

By way of preliminary remarks, the configuration parameters can beidentified using GUIDs. A GUID value is encoded as a string (e.g.,“{08bdf183-f2f2-4c80-ba86-0fd5257561c9}”). But in other implementations,the configuration parameters can be identified using other kinds ofidentifiers.

In most cases, the names assigned to the parameters and attributesreflect the respective roles served by the parameters and attributes.Thus, many of the parameters and attributes are self-explanatory basedon the assigned names themselves.

Common Parameters

The common parameters identify a set of parameters that are common toall encoders, packetizers, and multiplexers, etc., and which apply toall coding paradigms. Exemplary common parameters are described below.

-   -   An AVEncCommonFormatConstraint configuration parameter        identifies, for the encoder, a target format for parameter        legalization. Exemplary settings associated with this        configuration parameter include:        -   GUID_AVEncCommonFormatUnSpecified        -   GUID_AVEncCommonFormatDVD_V        -   GUID_AVEncCommonFormatDVD_DashVR        -   GUID_AVEncCommonFormatDVD_PlusVR        -   GUID_AVEncCommonFormatDVD_VFR        -   GUID_AVEncCommonFormatVCD        -   GUID_AVEncCommonFormatSVCD        -   GUID_AVEncCommonFormatATSC        -   GUID_AVEncCommonFormatDVB        -   GUID_AVEncCommonFormatMP3        -   GUID_AVEncCommonFormatHighMAT        -   GUID_AVEncCommonFormatHighMPV    -   An AVEncCodecType configuration parameter indicates the types of        coding schemes supported by a component. This configuration        parameter can specify the following exemplary types:        -   GUID_AVEncMPEG1Video        -   GUID_AVEncMPEG2Video        -   GUID_AVEncMPEG1Audio        -   GUID_AVEncMPEG2Audio        -   GUID_AVEncWMV        -   GUID_AVEndMPEG4Video        -   GUID_AVEncH264Video        -   GUID_AVEncDV        -   GUID_AVEncWMAPro        -   GUID_AVEncWMALossless        -   GUID_AVEncWMAVoice        -   GUID_AVEncDolbyDigitalPro        -   GUID_AVEncDolbyDigitalConsumer        -   GUID_AVEncDTS        -   GUID_AVEncMLP        -   GUID_AVEncPCM        -   GUID_AVEncSDDS    -   An AVEncCommonRateControlMode configuration parameter describes        the rate control mode to be used, e.g., constant bit rate (CBR),        variable bit rate (VBR), or quality mode. This parameter can        specify the following exemplary settings:    -   eAVEncCommonRateCBR=0    -   eAVEncCommonRatePeakConstrainedVBR=1    -   eAVEncCommonRateUnconstrainedVBR=2    -   eAVEncCommonRateQuality=3

RateQuality indicates that compression is driven by a quality target(controlled by CommonQuality), identifying a threshold quality to bemaintained in the encoding operation.

-   -   An AVEncCommonLowLatency configuration parameter indicates that        the output stream should be structured to have a low decoding        latency. For example, in video, this setting limits the GOP        structures that are allowed in an encoder to facilitate quick        switches. (For example, it is normally prudent in MPEG        processing to start the presentation of information at a key        frame, rather than a difference frame, e.g., a B or P frame.        This requirement, however, imposes a delay, because the encoder        must wait for a key frame to start presenting the information. A        low latency mode modifies the presentation of information such        that it accommodates quick switches, e.g., by presenting only        key frames, etc.).    -   An AVEncCommonMultipassMode configuration parameter indicates a        number of passes supported by the encoder. More specifically,        the encoder can process information in multiple passes. Often,        for instance, the encoder applies a first pass to collect        statistical parameters that provide information regarding the        nature of the encoding task, and then the encoder applies a        second pass to rebalance and better optimize the processing        based on the statistical parameters collected in the first pass.        With the AVEncCommonMultipassMode configuration parameter, users        can select a number of passes within an available range.        AVEncCommonPassStart (described below) is used to select which        pass is active.    -   An AVEncCommonPassStart configuration parameter starts the first        pass.    -   An AVEncCommonPassEnd configuration parameter ends the pass (by        writing TRUE). Writing FALSE aborts the multi-pass operation.    -   An AVEncCommonRealTime configuration parameter informs the        encoder that the application requires real time performance.        This parameter can specify the following exemplary settings:        -   0=no real time requirement        -   1=real time performance is required    -   An AVEncCommonQuality parameter (if available) controls the        quality during non-bit rate constrained encoding. This parameter        can specify the following exemplary settings:        -   100=maximum quality, larger output size        -   0=minimum quality, smaller output size    -   An AVEncCommonQualityVsSpeed configuration parameter defines        quality verses speed tradeoff considerations. This parameter can        specify the following exemplary settings:        -   0=low quality, high speed        -   100=high quality, lower speed    -   An AVEncCommonMeanBitRate configuration parameter specifies an        average long term bit rate target for CBR or VBR rate control        modes. This parameter supports media processing functionality        that has only a restricted set of allowed bit rates, such as        MPEG1 audio.    -   An AVEncCommonMeanBitRateInterval configuration parameter        indicates the interval that an average bit rate is specified        over (e.g., 100 ns units). For two-pass VBR, a value of 0        specifies the entire content. For a single-pass CBR, a value of        0 specifies that the component can choose the interval (e.g.,        0.5 sec).    -   An AVEncCommonMaxBitRate configuration parameter specifies a        maximum bit rate, and applies to CBR or VBR rate control modes.    -   An AVEncCommonMinBitRate configuration parameter specifies a        minimum bit rate, and applies to CBR or VBR rate control modes.        A forced minimum bit rate can be achieved by increasing the        quality. One use of this parameter is to prevent the encoder        from compressing certain information to the point where the        media processing functionality emits no output data (which has        the tendency to stall the media processing functionality). This        can happen, for example, when an encoder compresses a black        image. The minimum bit rate parameter prevents the encoder from        reducing its output to zero, and thereby reduces the potential        of such stalls.    -   An AVEncCommonBufferSize configuration parameter specifies the        size of the buffer to be used during encoding. This parameter        applies to CBR or PeakVBR rate control modes. For MPEG, this        parameter defines the VBV buffer size.    -   An AVEncCommonBufferInLevel configuration parameter specifies an        initial level of the buffer to support concatenation of streams.        This parameter applies to CBR or PeakVBR rate control modes. For        MPEG video, this parameter defines the initial VBV buffer level.    -   An AVEncCommonBufferOutLevel configuration parameter specifies a        level of the buffer at the end of an encoding operation to        support concatenation of streams. This parameter applies to CBR        or PeakVBR rate control modes. For MPEG video, this parameter        defines the VBV buffer level at the end of the encoding        operation. In general, one use of the AVEncCommonBufferInLevel        and AVEncCommonBufferOutLevel configuration parameters is to        facilitate video editing operations, e.g., by better controlling        the amount of information that is passed into and pulled out of        the buffer during a video editing operation.    -   An AVEncCommonStreamEndHandling configuration parameter        specifies the manner in which a stream is encoded upon its        termination. For example, a stream end event may truncate        information that is being presented. The        AVEncCommonStreamEndHandling configuration parameter defines how        the encoder handles this truncation, e.g., by permitting an        incomplete truncation or by “fixing up” the truncation such that        the encoder is allowed to encode data up to a more graceful        termination point. More specifically, this parameter can specify        the following exemplary settings:        -   eAVEncCommonStreamEnd_discardPartial=0        -   eAVEncCommonStreamEnd_ensureComplete=1

Common Post-Encode Statistical Parameters

-   -   An AVEncStatCommonCompletedPasses configuration parameter        indicates a completed number of passes. This parameter is        therefore meaningful for multi-pass encoding operations.

Common Video Parameters

-   -   An AVEncVideoOutputFrameRate configuration parameter specifies        an output frame rate defined by a numerator/denominator ratio,        specifying frames/second. This parameter can specify the        following exemplary settings:        -   23.97FPS=(24000/1001)        -   24FPS=(24/1)        -   25FPS=(25/1)        -   29.97FPS=(30000/1001)        -   30FPS=(30/1)        -   50FPS=(50/1)        -   59.94FPS=(60000/1001)        -   60FPS=(60/1)

The value of this parameter may be restricted to the connected inputrate.

-   -   An AVEncVideoOutputFrameRateConversion configuration parameter        provides output frame rate conversion control if the input frame        rate does not match the desired output frame rate. This        parameter can specify the following exemplary settings:        -   0=disable        -   1=enable        -   2=alias (This setting instructs the encoder not to perform            any interpolation, e.g., by merely changing the sample            timestamps; this is useful in various situations in which it            is desirable to simply pass information through the            component without transformation.)    -   An AVEncVideoPixelAspectRatio control parameter defines a        PixelAspectRatio, width/height. This parameter can specify the        following exemplary settings:        -   4×3 images of 704×480, 720×480, and 352×240 are 10/11        -   16×9 image of 704×480, 720×480, and 352×240 are 40/33        -   4×3 images of 704×576, 720×576, and 352×288 are 12/11        -   16×9 images of 704×576, 720×576, and 352×488 are 16/11        -   4×3 images of 320×240, 640×480, 1280×960 are 1/1        -   16×9 images of 320×240, 640×480, 1280×960 are 4/3        -   16×9 image of 1280×720, 1920×1080 are 1/1        -   16×9 image of 1440×1080 is 4/3        -   4×3 image of 144×1080 is 16/9    -   An AVEncVideoForceSourceScanType configuration parameter        indicates the nature of the output. This parameter can specify        the following exemplary settings:        -   0=use connecting media type        -   1=interlaced        -   2=progressive    -   An AVEncVideoNoOfFieldsToEncode configuration parameter defines        a number of fields to encode. This is to support telecine modes.        The value “0” specifies no limit.    -   An AVEncVideoNoOfFieldsToSkip configuration parameter defines a        number of fields to skip prior to encoding.    -   An AVEncVideoEncodeDimension configuration parameter specifies        the spatial dimensions of the coded stream if less than the        connected input source. This parameter can be used for cropping.    -   An AVEncVideoEncodeOffsetOrigin configuration parameter operates        in conjunction with AVEncVideoEncodeDimension. This parameter        specifies the start top left offset position of the coded image        for cropping purposes.    -   An AVEncVideoDisplayDimension configuration parameter specifies        the desired display dimension of the coded stream during decode.    -   An AVEncVideoOutputScanType configuration setting specifies the        manner in which the encoder is to interlace the output. This        parameter can specify the following exemplary settings:        -   0=progressive        -   1=interlace        -   2=same as input, or auto if not present        -   3=auto, ignore input    -   An AVEncVideoInverseTelecineEnable configuration parameter        enables internal inverse telecine when processing interlaced        input. For external telecine control, output scantype can be set        to “same as input.”    -   An AVEncVideoInverseTelecineThresholdLinear configuration        parameter specifies a linear range that controls a level at        which the encoder considers a video field redundant, and thereby        can be treated as a film frame. This parameter is useful for        performing inverse telecine from analog sources. This parameter        can specify the following exemplary boundary settings:        -   0=video field is less likely to be considered redundant        -   100=video field is very likely to be considered redundant    -   An AVEncVideoSourceFilmContent configuration parameter provides        a hint to the encoder as to the video source type with regard to        film content. This parameter can specify the following exemplary        settings:        -   eAVEncVideoFilmContentVideoOnly=0        -   eAVEncVideoFilmContentFilmOnly=1        -   eAVEncVideoFilmContentMixed=2    -   An AVEncVideoSourcelsBW configuration parameter indicates        whether the video source contains color. This parameter can        specify the following exemplary settings:        -   1=black and white (monochrome) source        -   0=color source    -   An AVEncVideoFieldSwap Bool configuration parameter reverses the        interlaced fields in the video source image. This parameter can        specify the following exemplary settings:        -   0=no swap        -   1=swap field order    -   AVEncVideoInputChromaResolution and        AVEncVideoOutputChromaResolution configuration parameters        specify the chroma subsampling structure. These parameters can        specify the following exemplary settings:        -   VideoChromaResolution_(—)444=1        -   VideoChromaResolution_(—)422=2        -   VideoChromaResolution_(—)420=3        -   VideoChromaResolution_(—)411=4    -   AVEncVideoInputChromaSubsampling and        AVEncVideoOutputChromaSubsampling configuration parameters        specify the chroma subsampling structure used to describe the        relationship of the chroma to the luma data. These parameters        can specify the following exemplary settings:        -   SameAsSource=0,        -   ProgressiveChroma=0×8,        -   Horizontally_Cosited=0×4        -   Vertically_Cosited=0×2        -   AlignedChromaPlanes=0×1    -   AVEncVideoInputColorPrimaries and AVEncVideoOutputColorPrimaries        configuration parameters specify the color primaries for output        (and default for input if not given). These parameters can        specify the following exemplary settings:        -   eAVEncVideoColorPrimaries_SameAsSource=0        -   eAVEncVideoColorPrimaries_Reserved=1        -   eAVEncVideoColorPrimaries_BT709=2        -   eAVEncVideoColorPrimaries_BT470_(—)2_SysM=3        -   eAVEncVideoColorPrimaries_BT470_(—)2_SysBG=4        -   eAVEncVideoColorPrimaries_SMPTE170M=5        -   eAVEncVideoColorPrimaries_SMPTE240M=6        -   eAVEncVideoColorPrimaries_EBU3231=7    -   AVEncVideoInputColorTransferFunction and        AVEncVideoOutputColorTransferFunction configuration parameters        specify the transfer parameter (variation of gamma) used to code        data. These parameters can specify the following exemplary        settings:        -   eAVEncVideoColorTransferFunction_SameAsSource=0        -   eAVEncVideoColorTransferFunction_(—)10=1 (Linear, scRGB)        -   eAVEncVideoColorTransferFunction_(—)18=2        -   eAVEncVideoColorTransferFunction_(—)20=3        -   eAVEncVideoColorTransferFunction_(—)22=4 (BT470-2 SysM)        -   eAVEncVideoColorTransferFunction_(—)22_(—)709=5 (BT709,            SMPTE296M, SMPTE170M, BT470, SMPTE274M, BT.1361)        -   eAVEncVideoColorTransferFunction_(—)22_(—)240M=6 (SMPTE240M,            interim 274M)        -   eAVEncVideoColorTransferFunction_(—)22_(—)8 bit_sRGB=7            (sRGB)    -   AVEncVideoInputColorTransferMatrix and        AVEncVideoOutputColorTransferMatrix configuration parameters        specify the conversion matrix used to convert from RGB to YCbCr.        These parameters can specify the following exemplary settings:        -   eAVEncVideoMatrixSameAsSource=0        -   eAVEncVideoMatrixBT709=1        -   eAVEncVideoMatrixBT601=2 (601, BT470-2 B,B, 170M)        -   eAVEncVideoMatrixSMPTE240M=3    -   AVEncVideoInputColorLighting and AVEncVideoOutputColorLighting        configuration parameters specify the intended lighting        conditions on the input (if not specified) and output data.        These parameters can specify the following exemplary settings:        -   eAVEncVideoColorLighting SameAsSource=0        -   eAVEncVideoColorLighting Unknown=1        -   eAVEncVideoColorLighting Bright=2        -   eAVEncVideoColorLighting Office=3        -   eAVEncVideoColorLighting Dim=4        -   eAVEncVideoColorLighting Dark=5    -   AVEncVideoInputColorNominalRange and        AVEncVideoOutputColorNominalRange configuration parameters        specify the nominal range that 0 to 1 is mapped to for RGB        formats (such as 0 to 255 or 16 to 235). These parameters can        specify the following exemplary settings:        -   eAVEncVideoColorNominalRange_SameAsSource=0        -   eAVEncVideoColorNominalRange_(—)0_(—)255=1, // (8 bit: 0            to255, 10 bit: 0 to 1023)        -   eAVEncVideoColorNominalRange_(—)16_(—)235=2, // (16 to 235,            64 to 940 (16*4 to 235*4)        -   eAVEncVideoColorNominalRange_(—)48_(—)208=3 // (48 to 208)    -   An AVEncInputVideoSystem configuration parameter specifies the        video system of the content. This parameter can specify the        following exemplary settings:        -   eAVEncMPVVideoFormatComponent=0        -   eAVEncMPVVideoFormatPAL=1        -   eAVEncMPVVideoFormatNTSC=2        -   eAVEncMPVVideoFormatSECAM=3        -   eAVEncMPVVideoFormatMAC=4        -   eAVEncMPVVideoFormatHDV=5    -   An AVEncVideoHeaderDropFrame configuration parameter specifies        the setting of the drop frame flag in the GOP Header.    -   An AVEncVideoHeaderHours configuration parameter specifies the        starting hours in the GOP header, e.g., 0 to 59.    -   An AVEncVideoHeaderMinutes configuration parameter specifies the        starting minutes in the GOP header, e.g., 0 to 59.    -   An AVEncVideoHeaderSeconds configuration parameter specifies the        starting seconds in the GOP header, e.g., 0 to 59.    -   An AVEncVideoHeaderFrames configuration parameter specifies the        starting frames in the GOP header, e.g., 0 to 24, or 0 to 29, or        0 to 23 for film.    -   An AVEncVideoDefaultUpperFieldDominant configuration parameter        sets the field dominance of the input video.    -   An AVEncVideoCBRMotionTradeoff configuration parameter indicates        the tradeoff between motion and still images when performing CBR        encoding. This parameter can specify the following exemplary        settings:        -   0=optimize for still images        -   100=optimize for motion    -   An AVEncVideoCodedVideoAccessUnitSize configuration parameter        specifies access unit size (and is used for still image        applications in VBR rate control).

Common Post-Encode Video Statistical Parameters

-   -   An AVEncStatVideoOutputFrameRate configuration parameter        specifies the average frame rate, in frames per second, of video        content. This value can be obtained after the completion of        encoding.    -   An AVEncStatVideoCodedFrames configuration parameter specifies        the number of video frames encoded by the media processing        functionality. This value is equal to AVEncStatVideoTotalFrames        minus any frames that were dropped due to bit rate constraints        or end of stream handling issues.    -   An AVEncStatVideoTotalFrames configuration parameter specifies        the number of video frames passed to the media processing        functionality.

Common Audio Parameters

-   -   An AVEncAudioSampleRate configuration parameter identifies the        sample rate of the audio.    -   An AVEncAudioInputChannelCount configuration parameter specifies        the total number of audio input channels to be coded.    -   An AVEncAudioChannelConfig configuration parameter specifies the        number of coded channels. This parameter can specify the number        of coded channels as follows:        -   0x01—LFE channel        -   0x02—Left (L)        -   0x04—Right (R)        -   0x08—Center (C)        -   0x10—left side (ls)        -   0x20—right side (rs)    -   An AVEncAudioIntervalToEncode configuration parameter specifies        the audio interval to encode. The value “0” specifies that no        limit applies.    -   An AVEncAudioIntervalToSkip configuration parameter specifies an        audio interval to skip (used in conjunction with IntervalEncode        to perform range encodings).    -   An AVEncAudioMapDestChannel0 configuration parameter specifies        the destination channel 0 mapping to source channel, zero based        mapping.    -   An AVEncAudioMapDestChannel1 configuration parameter specifies        the destination channel 1 mapping to source channel, zero based        mapping.    -   An AVEncAudioMapDestChannel2 configuration parameter specifies        the destination channel 2 mapping to source channel, zero based        mapping.    -   An AVEncAudioMapDestChannel3, configuration parameter specifies        the destination channel 3 mapping to source channel zero based        mapping.    -   An AVEncAudioMapDestChannel4 configuration parameter specifies        the destination channel 4 mapping to source channel, zero based        mapping.    -   An AVEncAudioMapDestChannel5 configuration parameter specifies        the destination channel 5 mapping to source channel, zero based        mapping.    -   An AVEncAudioMapDestChannel6 configuration parameters specifies        the destination channel 6 mapping to source channel, zero based        mapping    -   An AVEncAudioMapDestChannel7 specifies the destination channel 7        mapping to source channel, zero based mapping.    -   An AVEncAudioInputContent configuration parameter provides a        hint to the encoder that the content is either voice or music.        This parameter can specify the number of coded channels as        follows:        -   AVEncAudioInputContent Unknown=0        -   AVEncAudioInputContent Voice=1        -   AVEncAudioInputContent Music=2

Common Post-Encode Audio Statistical Parameters

-   -   An AVEncStatAudioPeakPCMValue configuration parameter specifies        the highest volume level occurring in audio content. This value        can be obtained upon the completion of encoding.    -   An AVEncStatAudioAveragePCMValue configuration parameter        specifies the average volume level occurring in audio content.        This value can be obtained upon the completion of encoding.    -   An AVEncStatAudioAverageBPS configuration parameter specifies        the average bits per second for quality-based VBR audio. This        value is also available after encoding. MPEG Video Encoding        Interface: MPV Encoder Specific Parameters    -   An AVEncMPVGOPSize configuration parameter specifies the maximum        distance, in pictures, from one GOP header to the next GOP        header.    -   An AVEncMPVGOPOpen configuration parameter specifies whether the        encoder produce closed GOPs. This parameter can specify the        following exemplary settings:        -   0=closed GOP        -   1=open GOP    -   An AVEncMPVDefaultBPictureCount configuration parameter        specifies the default number of consecutive B pictures to be        used between key frames (I/P). The encoder uses this as a hint        to the default GOP structure.    -   An AVEncMPVProfile configuration parameter specifies the        profile, e.g., MP. This parameter can specify the following        exemplary settings:        -   eAVEncMPVProfileSimple=1        -   eAVEncMPVProfileMain=2        -   eAVEncMPVProfileHigh=3    -   An AVEncMPVLevel configuration parameter specifies the level,        e.g., ML. This parameter can specify the following exemplary        settings:        -   eAVEncMPVLevelLow=1        -   eAVEncMPVLevelMain=2        -   eAVEncMPVLevelHigh 1440=3        -   eAVEncMPVLevelHigh=4    -   An AVEncMPVFrameFieldMode specifies the coding mode of a        picture. Specifying field mode will produce an MPEG picture for        each source image field. Specifying frame mode will produce a        single MPEG picture for each field pair. This parameter can        specify the following exemplary settings:        -   eAVEncMPVFieldFrameType FieldMode=0        -   eAVEncMPVFieldFrameType FrameMode=1

Advanced MPV Encoder Specific Parameters

-   -   An AVEncMPVAddSeqEndCode configuration parameter specifies that        a sequence end code should be added at the end of the stream.        This parameter can specify the following exemplary settings:        -   0=no sequence end code        -   1=add sequence end code on    -   An AVEncMPVGOPSInSeq configuration parameter specifies the        number of GOPs between sequence headers.    -   An AVEncMPVUseConcealmentMotionVectors configuration parameter        specifies the use of error concealment motion vectors, namely,        0=off, and 1=on.    -   An AVEncMPVSceneDetection configuration parameter specifies the        way in which scene detection should be handled by the encoder        with regard to GOP structures and bit allocation. This parameter        can specify the following exemplary settings:        -   eAVEncMPVSceneDetectionNone=0        -   eAVEncMPVSceneDetectionInsertIPicture=1        -   eAVEncMPVSceneDetectionStartNewGOP=2        -   eAVEncMPVSceneDetectionStartNewLocatableGOP=3 (that is,            start a new GOP where the first consecutive B pictures do            not reference the previous GOP)    -   An AVEncMPVGenerateHeaderSeqExt configuration parameter        specifies that sequence extension headers are generated, namely        0=no header and 1=generate header.    -   An AVEncMPVGenerateHeaderSeqDispExt configuration parameter        specifies that sequence display extension headers are generated,        namely 0=no header and 1=generate header.    -   An AVEncMPVGenerateHeaderPicExt configuration parameter        specifies that picture extension headers are generated, namely,        0=no header and 1=generate header.    -   An AVEncMPVGenerateHeaderPicDispExt configuration parameter        specifies that picture display extension headers are generated,        namely, 0=no header, 1=generate header.    -   An AVEncMPVGenerateHeaderSeqScaleExt configuration parameter        specifies that sequence scaleable headers are generated, namely        0=no header and 1=generate header.    -   An AVEncMPVScanPattern configuration parameter specifies the        macroblock scan pattern. This parameter can specify the        following exemplary settings:        -   eAVEncMPVScanAuto =0        -   eAVEncMPVScanZigZagScan=1        -   eAVEncMPVScanAlternateScan=2    -   An AVEncMPVIntraDCPrecision configuration parameter specifies        the DC Precision in bits (e.g., 8-11 is the usual range). The        value “0” indicates that the encoder automatically selects.    -   An AVEncMPVQScaleType configuration parameter specifies the        quantizer scale behavior. This parameter can specify the        following exemplary settings:        -   eAVEncMPVQScaleTypeAuto=0        -   eAVEncMPVQScaleTypeLinear=1        -   eAVEncMPVQScaleTypeNonLinear=2    -   An AVEncMPVIntraVLCTable configuration parameter specifies the        use of an alternate VLC table instead of a standard MPEG1 table.        This parameter can specify the following exemplary settings:        -   eAVEncMPVIntraVLCTableAuto=0        -   eAVEncMPVIntraVLCTableMPEG1=1        -   eAVEncMPVIntraVLCTableAlternate=2    -   An AVEncMPVQuantMatrixIntra configuration parameter specifies        intra matrix coefficients used by the encoder.    -   An AVEncMPVQuantMatrixNonIntra configuration parameter specifies        non-intra matrix coefficients used by the encoder.    -   An AVEncMPVQuantMatrixChromaIntra configuration parameter        specifies chroma intra matrix coefficients used by the encoder.    -   An AVEncMPVQuantMatrixChromaNonIntra configuration parameter        specifies chroma non-intra matrix coefficients used by the        encoder.

MPEG1 Audio Specific Parameters

-   -   An AVEncMPALayer configuration parameter specifies the coding        layer to be used. This parameter can specify the following        exemplary settings:        -   eAVEncMPALayer1=1        -   eAVEncMPALayer2=2        -   eAVEncMPALayer3=3    -   An AVEncMPACodingMode configuration parameter specifies the        coding mode. This parameter can specify the following exemplary        settings:        -   eAVEncMPACodingModeMono=0        -   eAVEncMPACodingModeStereo=1        -   eAVEncMPACodingModeDualChannel=2        -   eAVEncMPACodingModeJointStereo=3        -   eAVEncMPACodingModeSurround=4

Dolby Digital™ Audio Specific Parameters

-   -   An AVEncDDService configuration parameter specifies the service        provided by the bit stream. This parameter can specify the        following exemplary settings:        -   eAVEncDDBitStreamCM=0 (Main Service: Complete Main)        -   eAVEncDDServiceME=1 (Main Service: Music and Effects (ME))        -   eAVEncDDServiceVl=2 (Associated Service: Visually-Impaired            (VI))        -   eAVEncDDServiceHl=3 (Associated Service: Hearing-Impaired            (HI))        -   eAVEncDDServiceD=4 (Associated Service: Dialog (D))        -   eAVEncDDServiceC=5 (Associated Service: Commentary (C))        -   eAVEncDDServiceE=6 (Associated Service: Emergency (E))        -   eAVEncDDBitStreamVO=7 (Associated Service: Voice Over            (VO)/Karaoke)    -   An AVEncDDDialogNormalization configuration parameter specifies        the dialog normalization level in dB.    -   An AVEncDDCentreDownMixLevel configuration parameter specifies        the center down mix level in dB (e.g., 30 dB, 45 dB, 60 dB)    -   An AVEncDDSurroundDownMixLevel configuration parameter specifies        the surround down mix level in dB (e.g., 30 dB, 45 dB, 60 dB)    -   An AVEncDDSurroundMode configuration parameter specifies the        surround mode. This parameter can specify the following        exemplary settings:        -   eAVEncDDSurroundModeNotIndicated=0        -   eAVEncDDSurroundModeNo=1        -   eAVEncDDSurroundModeYes=2    -   An AVEncDDProductionInfoExists configuration parameter specifies        that the audio production information is present in the stream.    -   An AVEncDDProductionRoomType configuration parameter specifies        the room type in the audio production information. This        parameter can specify the following exemplary settings:        -   eAVEncDDProductionRoomTypeNotIndicated=0        -   eAVEncDDProductionRoomTypeLarge=1        -   eAVEncDDProductionRoomTypeSmall=2    -   An AVEncDDProductionMixLevel configuration parameter specifies        the mix level in the audio production information in dB.    -   An AVEncDDCopyright configuration parameter specifies whether        the content is copyrighted.    -   An AVEncDDOriginalBitstream configuration parameter specifies        whether the content is copied or original.    -   An AVEncDDDigitalDeemphasis configuration parameter enables        digital de-emphasis.    -   An AVEncDDDCHighPassFilter configuration parameter enables high        pass filtering for DC removal.    -   An AVEncDDChannelBWLowPassFilter configuration parameter enables        low pass filtering on each channel with an automatically        specified bandwidth.    -   An AVEncDDLFELowPassFilter configuration parameter enables 120        Hz low-pass filtering on the LFE input channel.    -   An AVEncDDSurround90DegreeePhaseShift configuration parameter        specifies a 90 degree phase shift on the surround input        channels.    -   An AVEncDDSurround3dBAttenuation configuration parameter        specifies a 3 dB attenuation on the surround input channels.    -   An AVEncDDDynamicRangeCompressionControl configuration parameter        specifies a dynamic range compression profile applied to the        input channels. This parameter can specify the following        exemplary settings:        -   eAVEncDDDynRangeCompNone=0        -   eAVEncDDDynRangeCompFilmStandard=1        -   eAVEncDDDynRangeCompFilmLight=2        -   eAVEncDDDynRangeCompMusicStandard=3        -   eAVEncDDDynRangeCompMusicLight=4    -   An AVEncDDRFPreEmphasisFilter configuration parameter enables a        RF pre-emphasis filter.    -   An AVEncDDSurroundExMode configuration parameter specifies the        Ex surround coding mode. This parameter can specify the        following exemplary settings:        -   eAVEncDDSurroundExModeNotIndicated=0        -   eAVEncDDSurroundExModeNo=1        -   eAVEncDDSurroundExModeYes=2    -   An AVEncDDPreferredStereoDownMixMode configuration parameter        specifies the preferred stereo down mix mode. This parameter can        specify the following exemplary settings:        -   eAVEncDDPrefStereoDownMixModeLtRt=0        -   eAVEncDDPrefStereoDownMixModeLoRo=1    -   An AVEncDDLtRtCenterMixLvl_x10 configuration parameter specifies        the LtRt center mix level (x10), e.g., one of 15, 0, −15, −30,        −45, −50, −999.    -   An AVEncDDLtRtSurroundMixLvl x10 configuration parameter        specifies the LtRt surround mix level (x10), e.g., one of 15, 0,        −15, −30, −45, −50, −999.    -   An AVEncDDLoRoCenterMixLvl x10 configuration parameter specifies        the LoRo center mix level (x10), e.g., one of 15, 0, −15, −30,        −45, −50, −999.    -   An AVEncDDLoRoSurroundMixLvl x10 configuration parameter        specifies the LoRo surround mix level (x10), e.g., one of 15, 0,        −15, −30, −45, −50, −999.    -   An AVEncDDAtoDConverterType configuration parameter specifies        the AD Converter type used to create source content (if not        present in the stream). This parameter can specify the following        exemplary settings:        -   eAVEncDDADConverterTypeStandard=0        -   eAVEncDDADConverterTypeHDCD=1    -   An AVEncDDHeadphoneMode configuration parameter specifies the        headphone mode. This function can specify the following        exemplary settings:        -   eAVEncDDHeadphoneModeNotIndicated=0        -   eAVEncDDHeadphoneModeNotEncoded=1        -   eAVEncDDHeadphoneModeEncoded=2

WMV Video Specific Parameters

-   -   An AVEncWMVKeyFrameDistance configuration parameter specifies        maximum time, in milliseconds, between key frames in the codec        output. The internal logic of the codec determines the actual        location of each key frame. The distance between any two key        frames may be less than the value of this property; however, it        should never be greater.    -   An AVEncWMVInterlacedEncoding configuration parameter indicates        whether interlaced video encoding will be used (e.g., 0=off and        1=on).    -   An AVEncWMVDecoderComplexity configuration parameter specifies        the device conformance template that is desired for use in video        encoding.    -   An AVEncWMVHasKeyFrameBufferLevelMarker configuration parameter        specifies whether the encoded video bit stream contains a buffer        fullness value with every key frame (e.g., 0=off and 1=insert        marker)    -   An AVEncWMVProduceDummyFrames configuration parameter indicates        whether the encoder produces dummy frame entries in the bit        stream for duplicate frames. If this value is 0, the media        processing functionality will not put any data in the bit stream        for duplicate frames.

WMV Post-Encode Statistical Parameters

-   -   An AVEncStatWMVCBAvg configuration parameter specifies the        resulting buffer window, in milliseconds, of a constrained        variable-bit-rate (VBR) stream at its average bit rate.    -   An AVEncStatWMVCBMax configuration parameter specifies the        resulting buffer window, in milliseconds, of a constrained        variable-bit-rate (VBR) stream at its peak bit rate.    -   An AVEncStatWMVDecoderComplexityProfile configuration parameter        specifies a device conformance template to which the encoded        content conforms. This value can be obtained upon the completion        of encoding.    -   An AVEncStatMPVSkippedEmptyFrames configuration parameter        indicates the number of skipped empty frame entries in the bit        stream for duplicate frames.

MPEG1/2 Packetizer Interface Parameters

A subset of the common parameter IDs defined earlier also apply to thepacketizer function. These are: AVEncCommonTargetApplication;AVEncCommonRealTime; and AVEncCommonPerformance. The followingparameters IDs are specific to the packetizer function.

-   -   An AVEncMP12MuxEarliestPTS configuration parameter comprises a        constraint parameter from the multiplexer that specifies the        earliest presentation time of the first access unit in the        stream.    -   An AVEncMP12MuxLargestPacketSize configuration parameter        comprises a constraint parameter from the multiplexer that        specifies the largest packet size of the PES stream.    -   An AVEncMP12MuxSysSTDBufferBound configuration parameter        comprises a constraint parameter from the multiplexer that        specifies the buffer size bound in bytes.    -   An AVEncMP12PktzSTDBuffer configuration parameter specifies the        size of the STD buffer(BSn) in bits (where        AVEncMP12PktzSTDBuffer≦AVEncMP12MuxSysSTDBufferBound).    -   An AVEncMP12PktzStreamID configuration parameter specifies the        stream ID of the elementary source. Stream IDs may be restricted        in range by MPEG specifications and DVD specifications.    -   An AVEncMP12PktzInitialPTS configuration parameter specifies the        presentation time of the first access unit in the stream (where        AVEncMP12PktzInitialPTS AVEncMP12MuxEarliestPTS).    -   An AVEncMP12PktzPacketSize configuration parameter specifies the        size of the packet in bytes (where        AVEncMP12PktzPacketSize≦AVEncMP12MuxLargestPacketSize).    -   An AVEncMP12PktzCopyright configuration parameter specifies that        the payload is copyright protected.    -   An AVEncMP12PktzOriginal configuration parameter specifies that        the payload is original, that is, not copied,

MPEG1/2 Multiplexer Interface Parameters

A subset of the common parameter IDs defined earlier also apply to themultiplexer function. These are: AVEncCommonTargetApplication;AVEncCommonRealTime; andAVEncCommonPerformance. The following exemplaryparameter IDs are specific to the multiplexer function.

-   -   An AVEncMP12MuxPacketOverhead configuration parameter specifies        the average packet overhead in the stream    -   An AVEncMP12MuxNumStreams configuration parameter specifies the        number of streams.    -   An AVEncMP12MuxEarliestPTS comprises a read only parameter that        specifies the earliest presentation time of the first access        unit in the stream.    -   An AVEncMP12MuxLargestPacketSize comprises a read only parameter        that specifies the largest packet size of the PES stream.    -   An AVEncMP12MuxInitialSCR configuration parameter specifies the        initial SCR in the multiplex.    -   An AVEncMP12MuxMuxRate configuration parameter specifies the        multiplex rate of the overall stream in bits per second.    -   An AVEncMP12MuxPackSize configuration parameter specifies the        pack size of the multiplex in bytes.    -   An AVEncMP12MuxSysSTDBufferBound configuration parameter        specifies the buffer size bound in bytes.    -   An AVEncMP12MuxSysRateBound configuration parameter specifies a        maximum rate of any mux rate in the multiplex.    -   An AVEncMP12MuxTargetPacketizer configuration parameter        specifies the pin index of the internal packetizer to select for        control. This parameter should be set before adjusting        packetizer parameters.    -   An AVEncMP12MuxSysFixed configuration parameter specifies that        fixed bit rate is in operation and controls the way SCR        increases over time. This parameter implies padding.    -   An AVEncMP12MuxSysCSPS configuration parameter specifies that        the output stream is a constrained system parameter stream.    -   An AVEncMP12MuxSysVideoLock configuration parameter indicates        that there is a specified, constant rational relationship        between the video sampling rate and the system clock.    -   An AVEncMP12MuxSysAudioLock configuration parameter indicates        that there is a specified, constant rational relationship        between the audio sampling rate and system clock.    -   An AVEncMP12MuxDVDNavPac configuration parameter indicates that        the multiplexer should generate the private DVD navigation        packet stream. The multiplexer should attempt to fill in as much        data as is reliably possible.

Exemplary Order for Setting Parameters

The interdependencies between the parameters require that masterparameters be set before their respective dependent child parameters.Setting up parameters in the correct order ensures that the application102 will not become locked out of certain parameter combinations due tomaster/slave relationships. This requirement can be met by dividing theparameters into functional groups, and then setting the parameters basedon their membership in the functional groups.

Consider, for example, the case of the MPEG video encoder parameters.The following listing identifies an exemplary order in which theseparameters can be set. Other orderings are possible, this being merelyone possible example.

-   -   System Level Parameters        -   AVEncCommonlDRealTime    -   General (minimal controls for starting an encode)        -   AVEncCommonIDTargetApplication        -   AVEncMPVIDMPEGType        -   AVEncMPVIDProfile        -   AVEncMPVIDLevel        -   AVEncCommonRateControlMode        -   AVEncCommonIDPerformance        -   AVEncCommonIDMeanBitRate        -   AVEncVideoIDNoOfFieldsToEncode    -   Key Video Controls        -   AVEncVideoIDSourceScanType        -   AVEncVideoIDDisplayFrameRate        -   AVEncVideoIDEncodeDimension        -   AVEncVideoIDSampleAspectRatio    -   Key Coding Controls        -   AVEncMPVIDLowDelay        -   AVEncMPVIDBPictures        -   AVEncMPVIDGOPOpen        -   AVEncMPVIDGOPSize        -   AVEncMPVIDFrameField    -   Advanced Video: Video Input        -   AVEncVideoIDEncodeOffsetTopLeft        -   AVEncMPVIDBwSrc        -   AVEncVideoIDFieldSwap    -   Advanced Video: Video Display        -   AVEncVideoIDDisplayDimension        -   AVEncMPVIDVideoFormat    -   Advanced Video: Film Content Control        -   AVEncVideoIDFilmInverseTelecine        -   AVEncVideoIDFilmContent        -   AVEncVideoIDInternalTelecineThreshold    -   Advanced Coding (advanced controls): Bitrate/Quality Control        -   AVEncCommonIDMaxBitRate        -   AVEncCommonIDMinBitRate        -   AVEncCommonIDQuality        -   AVEncVideoIDCodedVideoAccessUnitSize        -   AVEncMPVIDVBVBufferSize        -   AVEncMPVIDVBVBufferInLevel        -   AVEncMPVIDVBVBufferOutLevel    -   Advanced Coding (advanced controls): Sequence Level Control        -   AVEncMPVIDPicsInSeq        -   AVEncMPVIDProgressiveSequence        -   AVEncMPVIDAddSeqEndCode        -   AVEncMPVIDChromaFormat        -   VEncMPVIDColorPrimaries        -   AVEncMPVIDTransferCharacteristics        -   VEncMPVIDMatrixCoefficients        -   VEncMPVIDGenerateHeaderSeqExt        -   VEncMPVIDGenerateHeaderSeqDispExt        -   AVEncMPVIDGenerateHeaderPicExt        -   AVEncMPVIDGenerateHeaderPicDispExt        -   AVEncMPVIDGenerateHeaderSeqScaleExt    -   Advanced Coding (advanced controls): GOP Level Control        -   AVEncMPVIDGOPDropFrame        -   AVEncMPVIDGOPHours        -   AVEncMPVIDGOPMinutes        -   AVEncMPVIDGOPSeconds        -   AVEncMPVIDGOPFrames        -   AVEncMPVIDSceneDetection    -   Advanced Coding (advanced controls): Picture Level Control        -   AVEncMPVIDIntraDCPrecision        -   AVEncMPVIDQScaleType        -   AVEncMPVIDIntraVLC        -   AVEncMPVIDScanType        -   AVEncMPVIDConcealmentMotionVectors        -   AVEncMPVIDTFF    -   System Level Parameters        -   AVEncCommonIDGuaranteeAlllnputPUsCoded        -   AVEncVideoIDStatisticSceneDetected        -   AVEncMPVIDSeqHdrBitRate        -   AVEncMPVIDRFF        -   AVEncMPVIDStatisticSeqHdr        -   AVEncMPVIDStatisticSeqHdrExt        -   AVEncMPVIDStatisticSeqHdrScaleExt        -   AVEncMPVIDStatisticSeqHdrDispExt        -   AVEncMPVIDStatisticPicHdr        -   AVEncMPVIDStatisticPicHdrExt        -   AVEncMPVIDStatisticPicHdrDispExt        -   AVEncMPVIDStatisticGOPHdr        -   AVEncMPVIDStatisticSliceHdr

Transactions

In one exemplary implementation, groups of settings can be atomicallyset en bloc as respective groups. This can be accomplished by defining aproperty “eAV_Transaction.” A component can advertise its support fortransactions by supporting the property.

Mapping WMV/WMA Parameters

As a final topic, the following provides an exemplary list of mappingsfrom WMV/A parameters to the parameters defined above:

-   -   Bit rate control        -   AVEncCommonRateControlMode={g_wszWMVCVBREnabled}        -   AVEncCommonMeanBitRate={g_wszWMVCAvgBitrate}        -   AVEncCommonMaxBitRate={g_wszWMVCMaxBitrate}    -   Buffer control        -   AVEncWMVKeyFrameBufferLevelMarker={g_wszWMVCBufferFullnessInFirstByte}        -   AVEncCommonBufferSize={g_wszWMVCVideoWindow,g_wszWMACVoiceBuffer}    -   Encoding effort and quality control        -   AVEncCommonQualityVsSpeed={g_wszWMVCComplexityEx,        -   AVEncVideoCBRMotionTradeoff={g_wszWMVCCrisp}        -   AVEncCommonQuality={g_wszWMVCVBRQuality}    -   Conformance        -   AVEncWMVDecoderComplexity={g_wszWMVCDecoderComplexityRequested}    -   Multi pass control        -   AVEncCommonPassSelector={func(g_wszWMVCEndOfPass)}        -   AVEncCommonMultipass={g_wszWMVCPassesUsed}    -   Direct coding controls        -   AVEncWMVlnterlacedCoding={g_wszWMVCInterlacedCodingEnabled}        -   AVEncVideoKeyFrameDistance={g_wszWMVCKeyframeDistance}        -   AVEncWMVProduceDummyFrames={g_wszWMVCProduceDummyFrames}    -   Post-encode information        -   AVEncStatVideoOutputFrameRate={g_wszWMVCAvgFrameRate}        -   AVEncStatVideoCodedFrames={g_wszWMVCCodedFrames}        -   AVEncStatVideoTotalFrames={g_wszWMVCTotalFrames}        -   AVEncStatVideoSkippedEmptyFrames={g_wszWMVCZeroByteFrames}        -   AVEncStatWMVCBAvg={g_wszWMVCBAvg}        -   AVEncStatWMVCBMax={g_wszWMVCBMax}        -   AVEncStatWMVDecoderComplexityProfile={g_wszWMVCDecoderComplexityProfile}    -   Audio control        -   AVEncWMAIncludeNumPasses={g_wszWMACIncludeNumPasses}        -   AVEncAudioInputContent={g_wszWMACMusicSpeechClassMode}        -   AVEncWMAOrignalWaveFormat={g_wszWMACOriginalWaveFormat}        -   AVEncWMAOriginalSourceFormat={g_wszWMACSourceFormatTag}        -   g_wszWMACVoiceEDL=handled through MF infrastructure    -   Post-encode audio statistics        -   AVEncStatAudioAveragePCMValue={g_wszWMACAvgPCMValue,g            wszWMADRCAverageReference}        -   AVEncStatAudioPeakPCMValue={g_wszWMACAvgPCMValue,g_wszWMADRCPeakReference}

In closing, a number of features were described herein by firstidentifying exemplary problems that these features can address. Thismanner of explication does not constitute an admission that others haveappreciated and/or articulated the problems in the manner specifiedherein. Appreciation and articulation of the problems present in therelevant arts are to be understood as part of the present invention.More specifically, there is no admission herein that the featuresdescribed in the Background section of this disclosure constitute priorart. Further, the description of a limited set of problems in theBackground section does not limit the application of invention tosolving only those problems; it can be applied to problems andenvironments not expressly identified herein. Further, the subjectmatter set forth in the Summary section and the Abstract of thisdisclosure do not limit the subject matter set forth in the claims.

More generally, although the invention has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the invention defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as exemplary forms ofimplementing the claimed invention.

What is claimed is:
 1. A method for building media processingfunctionality, comprising: identifying a task to be performed;identifying at least one profile that provides predetermined informationused to implement the task; establishing at least one component toperform the task using: said at least one profile; capabilityinformation which describes the capabilities of a pool of availablecomponents; and a hierarchical organization of configuration parameters;and building the media processing functionality in a defined order basedon said established at least one component.
 2. The method of claim 1,wherein said at least one component includes one or more of: a componentimplemented by machine-readable instructions; a component implemented byhardware; or a component implemented by a combination ofmachine-readable instructions and hardware.
 3. The method of claim 1,wherein said at least one component comprises at least one of thefollowing types of components: a video encoder; an audio encoder; apacket-forming component; or a multiplexing component.
 4. The method ofclaim 3, wherein said at least one component comprises a set ofcomponents comprising at least one member from each of said types ofcomponents.
 5. The method of claim 1, wherein the establishing of saidat least one component comprises: creating said at least one component;configuring said at least one component; and logically associating saidat least one component with at least one downstream component.
 6. Themethod of claim 1, wherein the building in the defined order comprises:first, establishing at least one multiplexing component; second,establishing at least one packet-forming component per multiplexer inputstream; and third, establishing at least one media encoder.
 7. Themethod of claim 1, wherein said at least one component is a logicalsub-division of a larger, more complex component.
 8. The method of claim1, wherein the capability information contains configuration values orranges of values to be used in the selection of compatible components.9. The method of claim 1, wherein the hierarchical organization ofconfiguration parameters comprises at least one node that specifiesconfiguration parameters that apply to two or more different kinds ofcomponents.
 10. The method of claim 1, wherein the hierarchicalorganization of configuration parameters comprises at least one nodethat specifies configuration parameters that apply to two or moredifferent coding paradigms.
 11. The method of claim 1, wherein thehierarchical organization of configuration parameters comprises: a firstlevel which specifies configuration parameters that apply to an entirepool of components; a second level, which depends from the first level,which specifies groups of configuration parameters that apply todifferent respective classes of components within the pool ofcomponents; and a third level, which depends from the second level,which specifies groups of configuration parameters that apply todifferent respective general coding paradigms used within the pool ofcomponents.
 12. The method of claim 11, further comprising a fourthlevel, which depends from the third level, which specifies groups ofconfiguration parameters that apply to different respective species ofthe general coding paradigms identified in the third level.
 13. Themethod of claim 1, further including extending the hierarchicalorganization of parameters to include at least one new node, or toremove at least one existing node in the organization.
 14. The method ofclaim 1, wherein a first application uses a more detailed level of thehierarchical organization of parameters compared to a secondapplication.
 15. One or more machine-readable media containing machinereadable instructions for implementing the method of claim
 1. 16. Amethod for building media processing functionality, comprising:identifying a task to be performed; establishing a plurality ofcomponents to perform the task using a hierarchical organization ofconfiguration parameters; and building the media processingfunctionality in a defined back-to-front order based on the establishedcomponents, wherein the back-to-front order establishes at least onedownstream component prior to another component which is upstreamrelative to said at least one downstream component.
 17. The method ofclaim 16, wherein the building in the defined back-to-front ordercomprises: first, establishing at least one multiplexing component;second, establishing at least one packet-forming component permultiplexer input stream; and third, establishing at least one mediaencoder.
 18. One or more machine-readable media containing machinereadable instructions for implementing the method of claim
 16. 19. Anapparatus for building media processing functionality, comprising: aprofile store for storing a plurality of profiles, wherein each profileprovides predetermined information used to implement a task; acapability store for storing capability information which describes thecapabilities of a pool of available components; and interfacefunctionality for establishing at least one component to perform anidentified task using: at least one profile associated with theidentified task, stored in the profile store; the capabilityinformation, stored in the capability store; and a hierarchicalorganization of configuration parameters, wherein the interfacefunctionality is also configured to build the media processingfunctionality in a defined order based on said established at least onecomponent.
 20. The apparatus of claim 19, wherein the hierarchicalorganization of configuration parameters comprises: a first data fieldlevel which specifies configuration parameters that apply to an entirepool of components; a second data field level, which depends from thefirst data field level, which specifies groups of configurationparameters that apply to different respective types of components withinthe pool of components; and a third data field level, which depends fromthe second data field level, which specifies groups of configurationparameters that apply to different respective general coding paradigmsused within the pool of components.